Suppose that Google could redirect users to their Gmail service via the following URL:

https://www.google.com/?redirect_to=https://www.gmail.com
Copy

In this case, visiting www.google.com would result in your browser sending an HTTP request to the Google web server. The server would process this request and return a status code - typically 302, although it may sometimes be 301, 303, 307, or 308. This code would inform the browser that the page has been found, however, it would also tell it to make an additional HTTP request to www.gmail.com. This will be noted in the Location: header of the HTTP response. This header specifies where to redirect GET requests. An attacker could change the value of the redirect_to parameter and forward you to their malicious server.

Common redirection parameter names include url=, redirect=, next=, however, they may also be denoted by a single letter at times.

HTML <meta> tags can tell a browser to reload a page and make a GET request to a specified URL. This URL is defined in the tag's content attribute.

This is an example of such a tag:
<meta http-equiv="refresh" content="0; url=https://www.google.com/">

First, the content attribute defines the number of seconds the browser should wait before making the request to the URL. Secondly, it specifies the URL to make the request to.

Open redirects can be exploited by modifying the window's location property through the Document Object Model. This property denotes where a request should be redirected to.

An attacker may change the location property through any of the following ways:

window.location = https://www.google.com/  
window.location.href = https://www.google.com  
window.location.replace(https://www.google.com)
Copy

This type of open redirect is usually chained with some sort of XSS.